Extensible Markup Language (XML), has become a widespread file format for a large number of office-productivity tools, as well as for various types of Internet Protocol (IP) multimedia services, which may be distributed e.g. via the IP Multimedia Subsystem (IMS), or any other architectural framework which is adapted for delivery of IP multimedia services. The XML Configuration Access Protocol (XCAP) allows a device provided with XCAP Client functionality to read, write and modify application configuration data stored in XML format on a Server which is provided with XCAP Server functionality.
XML Document Management (XDM) is an Open Mobile Alliance (OMA) specification which enables XCAP Clients to access and manipulate XML documents stored on XCAP Servers. According to the OMA XDM standard, a Client having XCAP Client functionality may be referred to as an XDM Client (XDMC), while a corresponding Server may be referred to as an XDM Server (XDMS).
An Aggregation Proxy (AP) is the contact point for an XDMC to access XDM Resources stored in any XDMS. An AP is a Hypertext Transfer Protocol (HTTP) proxy that receives and routes individual XCAP requests to the correct XDMS or to a Cross-Network-Proxy, in case the XCAP request is related to an XDM Resource in a remote network. The AP may also perform authentication of the user behind the XDMC.
In communication networks with high loads of traffic, XDMS's may have to be scaled over several physical XDMS nodes. A user having an XDMC may accordingly be allocated to one of these XDMS nodes.
The current standard specifications in OMA and 3rd Generation Partnership Project (3GPP) does not specify how to find out which XDMS node, out of several XDMS nodes in the network, a user is allocated to. However a method referred to as “trial and error” may be used for this purpose. The trial and error method works as follows:
The user sends an XCAP request from an XDMC to an AP. If the AP doesn't find the user in its local storage it forwards the XCAP request to the first XDMS node. If the user is not allocated to the first XDMS node, the AP will receive an error response. The AP will proceed and forward the XCAP request to the second XDMS node. If the user is not allocated to the second XDMS node, the AP will again receive an error response. The AP will then continue to forward the XCAP request until it receives a successful response from the XDMS node where the user is actually allocated. It will then cache the user in its local storage. Next time the AP receives an XCAP request from this user, it will check its local storage and directly find out which XDMS node the user is allocated to, and it will then forward the XCAP request directly to that XDMS node.
A drawback with the “trial and error method” is that it causes a lot of signaling since many messages may be sent before the correct XDMS node is found. In addition, in case of a restart, the AP may need to go through the trial and error procedure from the beginning again in order to find the correct XDMS node, since a restart may cause the local storage of the AP to be cleared.